Skip to content

fix(mcp): stop quarantining an anonymous temp db on invalid project names (#1425) - #1437

Merged
DeusData merged 1 commit into
mainfrom
fix/1425-no-corrupt-litter-on-invalid-name
Aug 4, 2026
Merged

fix(mcp): stop quarantining an anonymous temp db on invalid project names (#1425)#1437
DeusData merged 1 commit into
mainfrom
fix/1425-no-corrupt-litter-on-invalid-name

Conversation

@DeusData

@DeusData DeusData commented Aug 4, 2026

Copy link
Copy Markdown
Owner

Fixes #1425.

Root cause (exactly as @dergachoff diagnosed)

project_db_path() yields "" for names failing validation → SQLite opens "" as an anonymous temp db → integrity check fails (no projects table) → quarantine_corrupt_store renders "%s.corrupt.%016llx" with the empty prefix → a relative .corrupt.<hex> file lands in the daemon's cwd on every such query, while the caller sees a clean "project not found".

Fix

Two guards, following the reporter's proposed design:

  1. resolve_store_internal skips the direct open when the path is empty and falls through to the existing fallback scan — which as a bonus can still resolve legacy dbs whose internal name predates validation.
  2. quarantine_corrupt_store refuses an empty path outright (belt-and-braces; logs empty store path instead of quarantining nothing).

Verification

  • New regression test: tools/call search_graph with "project":"bad name" from a temp cwd asserts the clean not-found error and zero .corrupt.* files in the cwd. RED on main (litter created), GREEN with the fix, RED again on revert.
  • mcp + mcp_mutation_guard: 214 passed / 2 skipped (pre-existing). lint-ci clean.

…ames (#1425)

A project name failing cbm_validate_project_name made project_db_path()
return an empty path, which cbm_store_open_path_query passed to SQLite -
and SQLite opens "" as an anonymous temp database. The healthy temp db
then failed the integrity check (no projects table) and
quarantine_corrupt_store rendered ".corrupt.<hex>" from the empty
prefix: a RELATIVE path, dropped as a 4 KB file into whatever directory
the daemon was started from, on every such query. The caller only ever
saw a clean 'project not found', so nothing pointed at the litter.

Two guards, per the reporter's analysis: resolve_store_internal skips
the direct open on an empty path and falls through to the existing
fallback scan (which can still resolve legacy dbs whose internal name
predates validation), and quarantine_corrupt_store refuses an empty
path outright (belt-and-braces - nothing at such a path is worth
quarantining).

Regression test: tools/call search_graph with project "bad name" from
a temp cwd asserts the clean not-found error AND that no .corrupt.*
file appears in the cwd. RED before (litter created), GREEN after,
RED again on revert.

Signed-off-by: Martin Vogel <martin.vogel.tech@gmail.com>
@DeusData
DeusData enabled auto-merge August 4, 2026 16:44
@DeusData
DeusData merged commit 24bee57 into main Aug 4, 2026
61 of 63 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Invalid project name resolves to empty db path — daemon litters .corrupt.<hex> files into its cwd

1 participant